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Index numbers are the raw, zero-based Btrieve index/key numbers. With ZBASE2/BDAC2, these 
are one-based. So index 0 here is index 1 to BDAC2. 

Notice most of the databases accessed via ODBC have an autoinc as a unique (duplicates not 
allowed) index. This keeps ODBC programs from choking. Btrieve automatically supplies a 
"system" index if a unique index is not supplied, but ODBC doesn't seem to recognize it. You 
must have a unique key as key 0. Name this field "recnum". 

Note that ZBASE2/BDAC2 combines consecutive date and time fields together into one field 
internally. That throws your field count from script off unless youYe aware of it. 

Please note this doc uses the term "database" sometimes to mean a specific table (in the ODBC 
sense of the word). Sorry if that causes confusion. 



BILLING. BTX 

recnum - autoinc 4 - index 0 
confjd - int 4 - index 1 
custjd - int 4 - index 2 

userjd - int 4 Blank unless this conf requires user ids. 

machjd - char 2 

line - char 4 

start_date - date 

startjime - time 

stop_date - date 

stopjime - time 

duration - int 4 

attribs - char 20 

Attribs used: 

A = Telephone user. 

B = IP user. 

The system generates one record per participant per conference. 



ADDRESS. BTX 

custjd - int 4 
userjd - int 4 
namel - char 20 
name2 - char 20 
home_phone - char 20 
work_phone - char 20 
email - char 20 
misd - char 20 
misc2-char 20 

Index 0: custjd + userjd 

index 1 : custjd Allows program to display the complete address book for a customer. 

Userjd 0 is the owner's address book entry for himself; userjd 0 is entered automatically by the 
system when the user registers. The userjd field links to a nextjjserjd field in the customer 
record. Tango uses that nextjjserjd field to populate the userjd field upon creation of new 



address book entries. The nextjjserjd field is thus a per customer code-incremented counter 
providing a unique userjd for each address book entry for a particular custjd. 



DISPLAY. BTX 

recnum - autoinc 4 - index 0 
confjd - int 4 - index 1 
userjd - int 4 
namel - char 20 
name2 - char 20 
attribs - char 20 
timeslot - int 4 - index 2 

Attribs used: 

A = Half duplex (muted) caller. 



CJJSER.BTX 

recnum - autoinc 4 - index 0 
confjd - int 4 - index 1 
userjd - int 4 
namel - char 20 
name2 - char 20 
attribs - char 20 
timeslot - int 4 - index 2 

Attribs: 

B: Set when a user has been added to a conference and is checked so that the user will not 

receive another conference-confirmation email. 
E: Set when a user has been added to a conference as default. If "E" is present, then the user 

will receive an email message about the conference, else user will not receive an email 
P: Set when a user has been added to a conference as default. If "P" is present, then the user will 

designated as a talk/listen, else user will be set as just listen. 



CONFJD.BTX 

confjd - autoinc 4 - index 0 
custjd - char 20 - index 1 
phonejium - char 20 
maxjjsers - char 3 
startjlate - date 
start_time - time 
stop_date - date 
stopjime - time 
duration - char 4 
attribs - char 20 
passjalk - char 20 
passjisten - char 20 

The attribs field holds: 

A: Set when conference is 'Advance' and thus the user will be prompted to enter a userjd. 

RTCONF.BTX 

confjd - int 4 - index 0 
realconf - int 2 - index 1 
curusers - int 2 



realconf is the actual conference number used by the conference engine. If no rtconf record for a 
conf_id exists, the voice node does a seekjast on this field, increments the value it finds, uses 
that new value to insert a new record for its confjd. If the rtconf database is empty, the voice 
node inserts a record for the confjd with realconf (and curusers) set to 1 . 
curusers increments as users join the conference. 



CALENDAR. BTX 

CALENDAR.DLL uses CALENDAR. BTX directly via Btrieve API calls. There is no applicable 
ODBC or BDAC2 definition for this database. Do not attempt to edit or modify this database via 
DDF Ease, Access, or any other method. The Tango application uses CALENDAR.DLL to 
perform resource allocation. 

Database fields: 
date - date 

segments - char 192 - A single two byte short int per segment. 

These two fields relate directly to the C type: 
{ 

btrieve_date_type date; 

unsigned short int segments[SEGMENTS_PER_DAY]; 
} 



